Subject: Correct version 0.12 DLSW (1 of 8)

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Fri, 19 Aug 94 18:00:59 PDT

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 1
X-Sun-Content-Length: 33

Here is the correct part 1 of 8

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: dlsw1.txt
X-Sun-Content-Lines: 630
X-Sun-Content-Length: 24184

RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

Network Working Group                         Alan K. Bartky
Request for Comments: XXXX                Sync Research Inc.
Obsoletes: RFC 1434                                   Editor

                                                 August 1994
       Data Link Switching: Switch-to-Switch Protocol
         EDITOR'S IN PROGRESS VERSION REVISION 0.12
                          8/15/94

THIS IS AN IN PROGRESS DOCUMENT AND DOES NOT NECESSARILY REPRESENT CONSENSUS
AGREEMENT AND IS FOR DISCUSSION AND REVIEW PURPOSES ONLY!!

   REVISION BARS CURRENTLY SHOW (AS BEST AS POSSIBLE) THE CHANGES FROM RFC 1434.
   REVISION BARS ARE NOT AVAILABLE FOR ASCII VERSION FOR EMAIL DISCUSSION PURPOSES
        - ALAN (your editor)

Status of this Memo

   This memo provides information for the Internet community.  It does not specify
   an Internet standard.  Distribution of this memo is unlimited.

Abstract

   This RFC describes use of Data Link Switching over TCP/IP. The RFC is being
   distributed to members of the Internet community in order to solicit their
   reactions to the proposals contained in it.  While the issues discussed may not
   be directly relevant to the research problems of the Internet, they may be
   interesting to a number of researchers and Implementers.

   This RFC was created as a joint effort of the Advanced Peer-to-Peer Networking
   (APPN) Implementers Workshop (AIW) Data Link Switching (DLSw) Related Interest
   Group (RIG).  The APPN Implementers Workshop is a group sponsored by IBM and
   consists of representatives of member companies implementing current and future
   IBM Networking interoperable products.  The DLSw Related Interest Group was
   formed in this forum in order to produce a single version of the Switch to
   Switch Protocol (SSP) which could be implemented by all vendors, which would fix
   documentation problems with the existing RFC 1434, and which would enhance and
   evolve the protocol to add new functions and features.

   This document is based on RFC 1434.  This document contains significant changes
   to RFC 1434 and therefore obsoletes that document.

   Any questions or comments relative to the contents of this RFC should be sent to
   the following Internet address:
     [email-masked].

   NOTE 1:  This is a widely subscribed mailing list and messages sent to this
   address will be sent to all members of the DLSw mailing list.  For specific
   questions relating to subscribing to the AIW and any of it's working groups send
   email to:
     [email-masked]
   Information regarding all of the AIW working groups and the work they are
   producing can be obtained by copying, via anonymous FTP, the file aiwinfo from
   the Internet host networking.raleigh.ibm.com, located in directory aiw.

   NOTE 2:  These mailing lists and addresses are subject to change.

AIW DLSw Related Interest Group                                  [Page 1]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

Table of Contents:

Table of Contents:.......................................2
Revisions:...............................................4
1. Introduction..........................................7
     1.1. Backwards Compatibility with RFC 1434..........7
2. Overview..............................................7
3. Transport Connection and SSP Message formats..........9
     3.1. SSP Frame Formats..............................10
     3.2. Address Parameters.............................14
     3.3. Correlators....................................16
     3.4. Largest Frame Size Field.......................17
     3.5. Message Types..................................18
4. Circuit Priority......................................20
     4.1. Frame format:..................................20
     4.2. Circuit Startup:...............................20
5. Capabilities Exchange Formats/Protocol:...............21
     5.1. Control Vector Id Range........................21
     5.2. Control Vector Order and Continuity............22
     5.3. Run-Time Capabilities Exchange.................22
     5.4. DLSw Capabilities Exchange Structured Subfields22
          5.4.1. Vendor Id (0x81) Control Vector.........22
          5.4.2. DLSw Version (0x82) Control Vector......23
          5.4.3. Initial Pacing Window (0x83) Control Vector     23
          5.4.4. SAP List Support (0x86) Control Vector..23
          5.4.5. Version String (0x84) Control Vector....24
          5.4.6. NetBIOS Support (0x85) Control Vector...24
          5.4.7. TCP Sessions (0x87) Control Vector......26
          5.4.8. Exclusivity (0x88) Control Vector.......27
          5.4.9. MAC Address List (0x89) Control Vector..27
          5.4.10. NetBIOS Name List (0x8A) Control Vector28
     5.5. Capabilities Exchange Responses................28
6. Pacing/Flow Control:..................................31
     6.1. Basic Overview.................................31
     6.2.Frame Format....................................32
     6.3. Granting Permission to Send Data...............33
          6.3.1. Repeat Window Operator..................34
          6.3.2. Increment Window Operator...............34
          6.3.3. Decrement Window Operator...............34
          6.3.4. Reset Window Operator...................34
          6.3.5. Halve Window Operator...................34
     6.4. Acknowledging a Flow Control Operator..........34
          6.4.1. Acknowledging a Reset Window Operator...35
     6.5. Capabilities Exchange Initial Window Size......35
     6.6. Session Startup................................35
     6.7. Example Receiving Implementations..............35
          6.7.1. Fixed Pacing Example....................36
          6.7.2. Adaptive Pacing Example.................37
     6.8. Other Considerations...........................39
          6.8.1. Protocol Violations.....................39
7. DLSw State Machine....................................41
     7.1. Data Link Switch States........................41
     7.2. State Transition Tables........................44
          7.2.1. DISCONNECTED State......................47
          7.2.2. RESOLVE_PENDING State...................48
          7.2.3. CIRCUIT_START State.....................49

AIW DLSw Related Interest Group                                  [Page 2]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

          7.2.4. CIRCUIT_PENDING State...................50
          7.2.5. CONNECT_PENDING State...................51
          7.2.6. CIRCUIT_ESTABLISHED State...............52
          7.2.7. CONTACT_PENDING State...................53
          7.2.8. CONNECTED State.........................54
          7.2.9. CIRCUIT_RESTART State...................55
          7.2.10. DISCONNECT_PENDING State...............56
          7.2.11. RESTART_PENDING State..................56
          7.2.12. HALT_PENDING State.....................57
          7.2.13. HALT_PENDING_NOACK State...............57
     7.3. NetBIOS Datagrams..............................58
8. Protocol Flow Diagrams................................60
     8.1. Connect Protocols..............................60
     8.2. Link Restart Protocols.........................71
     8.3. Disconnect Protocols...........................72
Acknowledgments..........................................73
References...............................................74
Editor's Address.........................................74

AIW DLSw Related Interest Group                                  [Page 3]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

Revisions:

    DLSw State Machines

   1 - Revision 1: January 24, 1994
   Changes made to original RFC 1434 FSMs reflecting the current 6611
   implementation of Data Link Switching.

   2 - Revision 2: April 4, 1994
       Added 'Failure of associated TCP connection' to state tables.

   3 - Revision 3: June 6, 1994
       Changed 'Failure of associated TCP connection' event to a more generic
   'transport failure' event
       Added:
       - separation of topology establishment and circuit establishment
       - resolution of collisions at during circuit start
       - support for non-activation XID3
       - note describing DGRMFRAME and DATAFRAME SSP messages from RFC 1434
         (adding circuit restart information)
   Deleted:
       - option of immediate UA response to SABME or delayed response
       - SSP message type 0x1D
       - ENTER_BUSY and EXIT_BUSY SSP messages from circuit FSMs

   4 - June 27, 1994, Alan K. Bartky Editor, Changes added during AIW meetings
   (editor's revision 0.01)

   Revision 0.10 Changes:
   -   Removed references to IBM 6611.
   -   Incorporated Steve Klein's Flow Diagrams
   -   Edited Wayne Clarks contribution to similar style as other sections and
   added section numbers.
   -   Removed DLSw state machine diagram (no longer up to date, too hard to
   maintain)
   -   Added Paul Brittain's contribution on Correlators and LF bits
   -   Removed Kushi & Dixon from Authors to Acknowledgments (per their requests).
   -   Moved Flow Control Byte to offset 15 from offset 1 so as to have common byte
   offset for data & control.
   -   Moved Backwards compatibility to section 1 from Flow control and changed
   wording.
   -   Removed Management considerations (to be defined in DLSw MIB document).
   -   Removed old text and diagrams under section 4.1.1. Connect protocols (they
   are out of date and are very Token-Ring specific, need text on separation of
   Data Link Connections at the start of the section (Steve Klein to give input)
   -   Added text to DLSw state machine intro. section 4.2. on how to determine
   bridging versus data link switching (use of SNA SAPs).  Change in text requested
   by G. Pandian of Cisco.
   -  Added text to NETBIOS_NQ_ex to allow for Name caching (request by G. Pandian
   of Cisco). Added to table at the end of Section 4.2.2.

   Revision 0.11 Changes (7/18/94 AKB):

   -   Added new text to introduction section describing AIW and DLSw groups.
   -   Changed footer to AIW DLSw RIG instead of A.K. Bartky
   -   Removed IBM from Header (leftover from original RFC)

AIW DLSw Related Interest Group                                  [Page 4]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

   -   Changed all occurrences of DLS to DLSw.
   -   Added list of control vectors to capabilities exchange section.

AIW DLSw Related Interest Group                                  [Page 5]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

   Revision 0.12 Changes (8/14/94)

   Connect group (LF propagation):
   -   Changed message type list.
   -   Changed  "don't care" flag to the "LF Size Control" flag and replaced all
   references to the old name.
   -   Changed the first sentence from *_ex to *_cs messages.
   -   Updated Resolve pending state table (section 4.2.2.2.)
   -   Updated Circuit start state table (section 4.2.2.3.)

   Flow Control:
   -   Added diagram and text for acceptable flow control messages
   -   Added Shannon Nix's contribution with minor editing on introductory
   Philosophy text.

   Priority:
   -   Added text from Gene Cox
   Capabilities exchange:
   -   Added and edited contribution from Frank Bordanaro of Cisco Systems.  PLEASE
   NOTE AND COMMENT ON EDITOR'S COMMENTS.

   Misc.:
   -   Added text on email addresses to send comments to.
   -   Rearranged sections to make easier to maintain and to have a logical
   progression (i.e. 1st TCP connection, then Priority selection, then capabilities
   exchange, etc.)
   -   Edited in some of the suggestions from Paul Brittain of DCL, Lakshman
   Garikapaty of DEC, Peter Gayek of IBM
   -   Ran Spelling Checker, corrected several spelling errors.

AIW DLSw Related Interest Group                                  [Page 6]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

1. Introduction

   Data Link Switching (DLSw) is a forwarding mechanism for the IBM SNA (Systems
   Network Architecture) and IBM NetBIOS (Network Basic Input Output Services)
   protocols.  It does not provide full routing, but instead provides switching at
   the Data Link layer (SNA and OSI layer 2) and encapsulation in TCP/IP for
   transport over the Internet.  This memo documents the Switch-to-Switch Protocol
   (SSP) that is used between Data Link Switches.

   A Data Link Switch (abbreviated also as DLSw in this document) can support  SNA
   (Physical Unit (PU) 2 and PU 4) systems and optionally NetBIOS systems attached
   to IEEE 802.2 compliantnetworks, as well as SNA (PU 2) systems attached to IBM
   Synchronous Data Link Control (SDLC) links.  For the latter case, the SDLC
   attached systems are provided with a LAN appearance within the Data Link Switch
   (each SDLC PU is presented to the SSP protocol as a unique MAC/SAP address
   pair).  For the Token-Ring LAN attached systems, the Data Link Switch appears as
   a source-routing bridge.  Token-Ring Remote systems that are accessed through
   the Data Link Switch appear as systems attached to an adjacent ring.  This ring
   is a virtual ring that is manifested within each Data Link Switch.

1.1. Backwards Compatibility with RFC 1434

   This document defines significant changes to RFC 1434 and does not state details
   on how to interoperate with RFC-1434 or "enhanced" implementations (e.g. those
   that added enter and exit busy flow control).  It is up to the implementor to
   refer to RFC 1434 and/or any other vendor's documentation in order to
   interoperate with a given vendor's implentation, if interoperability with pre
   AIW DLSw RIG standards is desired.

2. Overview

   Data Link Switching was developed to provide support for SNA and NetBIOS in
   multi-protocol routers.  Since SNA and NetBIOS are basically connection oriented
   protocols, the Data Link Control procedure that they use on the LAN is IEEE
   802.2 Logical Link Control (LLC) Type 2.  Data Link Switching also accommodates
   SNA protocols over WAN (Wide area Network) links via the SDLC protocol.

   IEEE 802.2 LLC Type 2 was designed with the assumption that the network transit
   delay would be small and predictable (i.e., a local LAN).  Therefore the LLC
   elements of procedure use a fixed timer for detecting lost frames.  When
   bridging is used over wide area lines (especially at lower speeds), the network
   delay is larger and it can vary greatly based upon congestion.  When the delay
   exceeds the time-out value LLC attempts to retransmit.  If the frame is not
   actually lost, only delayed, it is possible for the LLC Type 2 procedures to
   become confused.  And as a result, the link is eventually taken down.

   Given the use of LLC Type 2 services, Data Link Switching addresses the
   following bridging problems:

            DLC Time-outs
            DLC Acknowledgments over the WAN
            Flow and Congestion Control
            Broadcast Control of Search Packets
            Source-Route Bridging Hop Count Limits

AIW DLSw Related Interest Group                                  [Page 7]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

   NetBIOS also makes extensive use of datagram services that use LLC Type 1.  In
   this case, Data Link Switching addresses the last two problems in the above
   list.

   The principal difference between Data Link Switching and bridging is that DLSw
   terminates the Data Link Control whereas bridging does not. The following figure
   illustrates this difference based upon two end systems operating with LLC Type 2
   services.

       Bridging
       --------             Bridge           Bridge
       +------+             +----+           +----+             +------+
       | End  | +---------+ |    +-----/     |    | +---------+ | End  |
       |System+-+   LAN   +-+    |    /------+    +-+   LAN   +-+System|
       |      | +---------+ |    |  TCP/IP   |    | +---------+ |      |
       +------+             +----+           +----+             +------+
      Info------------------------------------------------------->
          <-------------------------------------------------------RR

       Data Link Switching
       -------------------
       +------+             +----+           +----+             +------+
       | End  | +---------+ |    +-----/     |    | +---------+ | End  |
       |System+-+   LAN   +-+DLSw|    /------+DLSw+-+   LAN   +-+System|
       |      | +---------+ |    |  TCP/IP   |    | +---------+ |      |
       +------+             +----+           +----+             +------+
      Info------------------->   -------------> Info
          <-------------------RR                 ---------------->
                                                 <----------------RR

              Figure 1.  Data Link Switching Contrasted to Bridging

   In traditional bridging, the Data Link Control is end-to-end.  Data Link
   Switching terminates the LLC Type 2 connection at the switch.  This means that
   the LLC Type 2 connections do not cross the wide area network.  The DLSw
   multiplexes LLC connections onto a TCP connection to another DLSw.  Therefore,
   the LLC connections at each end are totally independent of each other.  It is
   the responsibility of the Data Link Switch to deliver frames that it has
   received from a LLC connection to the other end.  TCP is used between the Data
   Link Switches to guarantee delivery of frames.

   As a result of this design, LLC time-outs are limited to the local LAN (i.e.,
   they do not traverse the wide area).  Also, the LLC Type 2 acknowledgments
   (RR's) do not traverse the WAN, thereby reducing traffic across the wide area
   links.  For SDLC links, polling and poll response occurs locally, not over the
   WAN.  Broadcast of search frames is controlled by the Data Link Switches once
   the location of a target system is discovered.  Finally, the switches can now
   apply back pressure to the end systems to provide flow and congestion control.

   Data Link Switching uses LAN addressing to set up connections between SNA
   systems.  SDLC attached devices are defined with MAC and SAP addresses to enable
   them to communicate with LAN attached devices.  For NetBIOS systems, Data Link
   Switching uses the NetBIOS name to forward datagrams and to set up connections
   for NetBIOS sessions.  For circuit establishment, SNA systems send TEST (or in
   some cases, XID) frames to the null (0x00) SAP.  NetBIOS systems have an address
   resolution procedure, based upon the Name Query and Name Recognized frames, that
   is used to establish an end-to-end circuit.

AIW DLSw Related Interest Group                                  [Page 8]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

   Since Data Link Switching may be implemented in multi-protocol routers, there
   may be situations where both bridging and switching are enabled.  SNA frames can
   be identified by their link SAP.  Typical SAP values for SNA are 0x04, 0x08, and
   0x0C.  NetBIOS always uses a link SAP value of 0xF0.

3. Transport Connection and SSP Message formats

   Data Link Switches can be in used in pairs or by themselves.

   A Single DLSw internally switches one data link to another without using TCP
   (DLC(1) to DLC(2) in the figure below).  This RFC does not go into details on
   how to implement this feature and it is not a requirement to support this RFC.

   A paired DLSw multiplexes data links over a reliable transport using a Switch-
   to-Switch Protocol (SSP).  This RFC documents the frame formats and protocols
   for this multiplexing between Data Link Switches.  The initial implementation of
   SSP uses TCP as the reliable transport between Data Link Switches.  However,
   other transport connections such as OSI TP4 could be used in the future.

       +-----------------------------------------------+Switch-to-Switch
       |               DLC Interfaces                  | Protocol (SSP)
       |+------------+   DLC Request    +------------+ |
       ||    Data    |<---------------- |            | |Send SSP Frame
       ||    Link    | DLC Indication   |            | |-------------->
       ||  Control 1 |----------------->|            | |
       |+------------+                  | Data Link  | |
       |+------------+   DLC Request    |  Switch    | |
       ||    Data    |<---------------- |            | |Rec. SSP Frame
       ||    Link    | DLC Indication   |            | |<-------------
       ||  Control 2 | ---------------->|            | |
       |+------------+                  +------------+ |
       |                   Multi-Protocol Router       |
       +-----------------------------------------------+

                        Figure 2.  DLSw System Diagram

   Before Data Link Switching can occur between two routers, they must establish
   two TCP connections between them.  Each Data Link Switch will maintain a list of
   DLSw capable routers and their status (active/inactive).  After the TCP
   connection is established, SSP messages are exchanged to establish the
   capabilities of the two Data Link Switches.  Once the exchange is complete,  the
   DLSw will employ SSP control messages to establish end-to-end circuits over the
   transport connection.  Within the transport connection is a specific set of
   DLSw message units.  The message formats and types for these PDUs are documented
   in the following sections.

   The default parameters associated with the TCP connections between Data Link
   Switches are as follows:

               Socket Family     AF_INET        (Internet protocols)
               Socket Type       SOCK_STREAM    (stream socket)
               Read Port Number  2065
               Write Port Number 2067

AIW DLSw Related Interest Group                                  [Page 9]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

   Two or more Data Link Switches may be attached to the same LAN, consisting of a
   number of token-ring segments interconnected by source-routing bridges.  In this
   case, a TCP connection is not defined between bridges attached to the same LAN.
   This will allow using systems to select one of the possible Data Link Switches
   in a similar manner to the selection of a bridge path through a source- routed
   bridged network.  The virtual ring segment in each Data Link Switch attached to
   a common LAN must be configured with the same ring number.  This will prevent
   LAN frames sent by one Data Link Switch from being propagated through the other
   Data Link Switches.

3.1. SSP Frame Formats

   The following diagrams show the two message headers for traffic between Data
   Link Switches.  The control message header is used for all messages except
   information messages and Independent Flow Control Messages.  The information
   message header is 16 bytes long, and the control message header is 72 bytes
   long.  The first sixteen bytes of the control message header are identical to
   the information message header.

AIW DLSw Related Interest Group                                  [Page 10]